[Previous] [Next] [Index] [Thread]

ANNOUNCE: AT&T Chrg_HTTP for Electronic Publishing

AT&T Chrg_HTTP for Electronic Publishing

I have implemented a protocol called chrg_http for the eletronic
publishing purpose. It is based on the Kerberos V5 beta4.2.
The Httpd server is based on Cern_http3.0pre6. The user interface is
based on NCSA Mosaic2.4 with WWW library Version2.
The chrg_http protocol is the same as the http protocol specified by
Tim Berners-Lee of Cern except the authentication part.
In Lee's protocol, the xmosaic client sends the following
authentication to the server:
Authentication: Kerberos kerberosauthenticationparameters
There are some disadvantage of the specification.
1. Mutual authentication can not be implemented (How does the
   server authenticate itself to the client)
2. The "kerberosauthenticationparameters" part is not checksumed,
   maybe modified
3. KRB_AP_REQ and KRB_AP_REQ messages are not just one-round of
  communication between a client and a server. They are at least
  two-round of communication, they are impossible to be include into
  some "kerberosauthenticationparameter". The kerberos communication
  routine (mutual auth, checksum and ticket passing) between client
  and server are encrypted with a session key,
  so it is more secure since WWW sends msg around unencrypted, that is maybe
  good for documents and commmands, but not good for ticket and
  other crendential info passing.

The reason that I did not put the kerberos auth into HTTP directly is due to
the back compatibility problem. If I had done that, our client would not
be able to http to old httpd server.

There are some restrictions of the chrg_http protocol:
If the client and the server are not in the same realm, the
client and the server have to authenticate cross_realm.
This means that the kerberos server on the client's realm has to
share a secret with that of the server's realm, or the server
has to register a secret in the client's realm, or the clients
have to register  in the Server's realm. Otherwise, the authentication
does not work.

The advantage of the protocol is that the client does not have to
pass a decoded password thru open network.

The implementation was based on the Bill Model,
the server authenticates the client, passes the information and
bills the client later. Since the authentication is secure,
the bill sent to the client is accurate and is difficult to abuse it.
Since it is based on kerberos, it does not scale well, I am going
to extend it from Bill Model to Eletronic Check Model if I have time
in the future. The basic idea is to assign public keys to every kerberos
realm (such as cmu.edu, research.att.com, mit.edu, etc). Whenever a client
wants to access a server, the client authenticate himself to his local
kerberos server. The kerberos server will sign check for this client
and the client can present the check to the server and the server verifies
it and present the check to the server's bank to get the money.

This work was done when I was a summer intern of AT&T Bell Labs in  Murray
Hill this summer. you can see the demo by trying  the following to see how the
 chrg_httpd server works.

http://hecatomb.research.att.com:8001/jsac/charge/demo.htm

But to run the chrg_http protocol, you have to run our modified xmosaic.
Have fun!

--ltang
Follow-Ups: